Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 081 / matrix.arc / MATRIX.DOC next >

Wrap

Text File | 1987-05-11 | 53.3 KB | 1,456 lines

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░ ░░░░░░░ ░░░ ░░░ ░░░ ░░░░ ░░ ░░░░░░ ░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓▓▓▓▓▓▓░ ▓▓▓▓▓▓░░ ▓▓▓▓▓▓▓░░░ ▓▓▓▓▓▓░ ▓▓▓▓░░░░░ ▓▓▓▓░░░░░░ ░░░░ ▓▓▓░░░░ ▓▓▓░░ ▓▓▓▓▓▓▓▓░ ▓▓▓▓▓▓▓▓░ ▓▓▓▓▓▓▓▓░░░▓▓▓▓▓▓░░ ▓▓░░░░░░░ ▓▓░░░░░░░ ░░░░ ▓▓▓▓░░ ▓▓▓▓░░ ▓▓░░░ ▓▓░░▓░ ▓▓░░▓░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░ ▓▓░░░░░ ▓▓░░░░░░░░ ░░░░ ▓▓░▓▓ ▓▓ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░░ ▓▓░░░ ▓▓░░░░░░░░░ ░░░░ ▓▓░░░▓░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░░░ ▓▓ ▓▓░░░░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓ ▓▓░░░░ ▓▓░░░░ ▓▓ ▓▓░░░░ ▓▓░░░░░░░░ ▓▓▓▓░░░░░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓▓▓▓▓▓▓░░░░ ▓▓░░░░ ▓▓▓▓▓▓▓░░░░░ ▓▓░░░░░░░░░ ▓▓░░░░░░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓▓▓▓▓▓▓░░░░ ▓▓░░░░ ▓▓▓▓▓▓░░░░░░ ▓▓░░░░░░░░ ▓▓▓▓░░░░░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░ ▓▓░░░░░ ▓▓░░░░░░░ ▓▓░ ▓▓░░░░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░░░ ▓▓░░░ ▓▓░░░░░░░░░ ░░░░ ▓▓░░░░░░ ▓▓░░ ▓▓░░░ ▓▓░░░░ ▓▓░░░░ ▓▓░░░ ▓▓░░ ▓▓ ░░░░ ▓▓░░░░░ ▓▓░░░░░░░░ ░░░ ▓▓░░░░░ ▓▓░ ▓▓░░ ▓▓░░░ ▓▓░░░ ▓▓░░░ ▓▓░░ ▓▓▓▓▓▓░ ▓▓░░░░░░░ ▓▓░░░░░░░ ░░░░▓▓▓▓░░░░░▓▓▓▓░▓▓▓▓░░▓▓▓▓░░░▓▓▓▓░░░▓▓▓▓░░░▓▓▓░░▓▓▓▓▓▓░░▓▓▓░░░░░░░░▓▓▓░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ +---------------------------------------------+ | | | "Arrogance is the mother of invention." | | | | - Guido Palermo - | | Opus Bylaws and Covert Action Committee | | | | | | | | Actually, Guido just claims this | | quote. When I checked, the quote's | | serial number had been filed off... | | so it's impossible to tell for sure. | | | +---------------------------------------------+ +-----------------------------------------------------------+ | | | The Opus Computer-Based Conversation System | | (c) Copyright 1987, Wynn Wagner III, All Rights Reserved | | | | YOOHOO and YOOHOO/2U2 are | | Copyright 1987, Wynn Wagner III, All Rights Reserved | | | +-----------------------------------------------------------+ WHAT YOU ARE READING -------------------- Because of a great deal of interest in Opus outbound, we're releasing this document before the release of the code. This file explains the theory behind Opus outbound in a general sort of way. The document is preliminary. Everything here is subject to change. ------------------------------------------------------------------------------ Opus now supports outbound matrix messages. This file is a general explanation of the methods involved with sending messages from your system to other systems. IMPORTANT --------- You won't find any step-by-step information here. This is a discussion on the theories behind Opus Outbound. The reason is that the ideas are going to seem a little different. I'll go further and say that if you skip this background information, you are going to have a hard go of it later! I feel it's important to setup your head for all of this before you setup your computer. SIMPLE ------ Doing outbound mail with Opus is fairly simple. In fact, getting that message across has been one of the toughest jobs. Some of the beta testers say most of their work fell into one of two categories: * deleting lines of batch and routing files * convincing themselves that fewer lines of instruction will do just as much work IDEA #1 ------- With Opus, "mail events" are less important. To be thoroughly honest about it, they don't even exist. Instead, we'll be dealing with "behavior windows." With an event, you have to give every detail... making statements that are procedural in nature. With a behavior window, you paint with a wide brush telling the system what to do with classes of remote systems. When systems could handle matrix traffic only during special times, routing and times were important. Because more and more systems can process mail at any time, the idea of a schedule becomes less important. The item of prime importance in Opus is COST. We are going to try to relieve you of the tedius details of scheduling and concentrate on doing things for the least cost. There'll be more on this later. IDEA #2 ------- Another new idea deals with the way bundles are created. A "bundle" is what some other systems call a "packet." In network operations, a packet has a special meaning... a meaning that has nothing to do with network mail. An "XModem Block" is a packet in network terminology. To avoid confusion with an established word, Opus docs use "bundle." Anyway... you are probably used to seeing bundles generated several times. With some programs, bundles are build every time a mail schedule starts. As a result, one message may be put into a bundle several times. With Opus, bundles are built once by an external program called oMMM (the Opus Matrix Message Masher). Although I wrote the original oMMM, Bob Hartman has adopted the program and has added lots of widgets and handy features. IDEA #3 ------- Opus uses "Continuous Mail". If you are already using a program that supports "Crash Mail", then you understand a liitle of what Continuous Mail does. Continuous Mail differs from Crash Mail in a couple of areas. In other mailer systems, you would mark a message a "Crash" meaning that you wanted this message to go out NOW. These mailer programs would shut down human caller access to the bbs and try like the dickens to get that message through. Opus uses Continuous Mail, meaning that this is a message going to a system that can accept mail at any time of the day. Opus does not make any frantic attempts to dial out, rather it will try to deliver the mail in between human callers. The actual routine to determine if Opus should call or not is based on the number of seconds Opus has been free without either a human caller or a previous mail attempt. It is a random number of seconds, between 30 seconds and 2 minutes. You can control this behavior with "Z-Event Windows" that we will cover later. IDEA #4 ------- The driving forces of outbound traffic are file names! You'll have a special sub-directory set aside just for bundles and other matrix files. It's a sub-directory that belongs to Opus and shouldn't have anything else put in there. Opus will maintain this sub-directory for you. It's kind of a "black hole." David Finster says it takes some getting used to. As soon as you run oMMM, messages that are marked KILL/SENT in your matrix message area will disappear. They haven't been sent, yet. They're just bundled and ready to go. File names are important to opus... BUNDLE NAMES ------------ The file names of the bundles tell Opus how to treat the different bundles. Here's a typical bundle name: 12345678.OUT That says the bundle is for 1234/5678. The numbers are in hex (base 16). The ".OUT" means it is a regular bundle. Other bundle extensions include: .HUT ... hold the bundle for pickup .CUT ... the other system can receive continuous mail One nice thing is that you can manually change the file's extension if you need to. That would change the behavior of the bundle when Opus sees it next. The oMMM program knows about these extensions and creates them based on information you put into the oMMM control file. You'll have statements like this: HOLD 124/102 That would create a .HUT bundle file, and Opus will hold that packet for 124/102 to call and pick it up. FLOW FILE NAMES --------------- Files are also sent through the matrix. oMMM builds and maintains a file that tells Opus what files to send (or hold) for whom. A typical "file attach" file might be named: 12345678.FLO Other flow file extensions are: .HLO ... hold these files for pickup .CLO ... the other system can receive continuous mail A flow file is just a text file. It contains a list of files that are to be sent to another system: e:\net\outbound\00096581.mo1 e:\pascal\notes.doc File names in a flow file never include wildcards. ARCHIVED MESSAGES ----------------- The oMMM program will put messages into archives for you. Details on how this is done can be found in the oMMM documentation. The point here is that oMMM combines the functionality of "generating packets" with that of programs like ArcMail. oMMM creates archives using the same numbering convention as other message archive programs. The file name is the difference between the sender's net/node and the receiver's net/node. The file extension is ".MO#" where `#' is a number between 0 and 9. In this case, MO stands for "messages for outbound" and has nothing to do with Monday. oMMM will NOT produce a "TU" or "WE" (etc) file. EXAMPLE ------- So far, we've covered bundles and flow files. We've also hit on some of the high points of oMMM. Here's the flow of a message... Let's say I've written a message to Mike Kelleher. The message is in my matrix message area and is flagged KILL/SENT. oMMM is executed to convert the message into a bundle. In my control file for oMMM, I have this: CRASH 161/521 161/ALL The word "crash" is VERY misleading. We just haven't come up with a better word, yet. CRASH in this case means that Mike (161/521) runs a system that can receive continuous mail. This control file line tells oMMM to build a message archive to 161/521. In the archive will be any messages to Mike (521) as well as messages to anybody else in net 161. When the flurry of activity dies down, you'll have a file called "00A10209.CLO" and another one with an ".MO1" extension. The message is now in queue. +-------------------------------+ | | | "Roads? Where we're going we | | don't need roads." | | | | - from Back To The Future | | | +-------------------------------+ ENTER OPUS, STAGE RIGHT ----------------------- Opus can tell by looking at the outbound sub-directory (called the HOLD AREA) that there's a bundle for Mike. Opus can tell that Mike's system can receive continuous mail. It's in the middle of the afternoon. Phone rates between Dallas and San Francisco are the highest they'll be all day. It's a bad time to call. We aren't controlling calling times because of our software. The software doesn't care. Both ends can handle matrix traffic at any time. We're controlling calling times based on the phone rates. I have a Z-EVENT set in Opus that tells the system to make calls only to local systems that can receive continuous mail. Z-EVENT: The Behavior Window ---------------------------- A Z-EVENT is setup using the Opus event manager. It starts out looking like any other event... except that it has a Z for a tag. In addition to the start time and event length, there are several yes/no questions that go along with a Z-EVENT: Local only? .......... YES: only make calls to systems whose cost field is 0. NO: it's okay to make calls that cost money #CM only? ............ YES: only call systems who have .CUT and/or .CLO files NO: not restricted to continuous mail systems Mail only? ........... YES: don't let human callers on-line, concentrate on mail. NO: humans and the matrix coexist. File requests ok? .... YES: let other systems make file requests NO: don't allow file requests During the day, I have a Z-EVENT that has LOCAL, #CM, and FILE REQUESTS set to YES. I don't want to make long-distance calls, and I don't want to call systems that can't handle mail on a continuous basis. POOR MIKE, JUST HANGING OUT --------------------------- So, there sits the .CLO file for Mike (see EXAMPLE above). Although it says Mike's board can accept mail on a continuous basis, the COST field in the node list for 161/521 isn't zero. It's a long distance call. Opus will not call 161/521. At midnight, the phone rates are lower. I have another Z-EVENT that allows #CM only. In other words, at midnight I drop the requirement that all calls be local. At that point, Opus will start trying to send the stuff. (Knowing Mike's board, it will take all night to get it through!) Z-EVENT OVERVIEW ---------------- Here's how my Z-Events go... Daytime ..... #CM, LOCAL Overnight ... #CM NMH ......... MAIL_ONLY For NMH (National Mail Hour), I drop the #CM requirement. That let's Opus send to systems that can't handle continuous mail. The point to all of this is that messages stay bundled all the time. What changes is the behavior of Opus. THAT'S ABOUT IT --------------- At this point, the standard reaction is "I have some special cases that this won't handle. I have several pages of routing and batch files to do all this special stuff." This is my experience: sysop thought patterns are what complicate matters. Possibly there are some special cases that Opus outbound can't handle. I haven't seen any. In the rest of this file, you'll find excerpts of NEW.DOCs form various beta releases. There are details on the HOLD AREA (sub- directory), file requests, and dialing scripts. Control file additions ---------------------- Matrix Hold Area ---------------- Opus wants its own sub-directory for outbound traffic. Declare that area like this: MATRIX HOLD_AREA C:\Opus\Outbound\ The system will maintain that sub-directory for you. There are no user-servicable parts inside. That's not really true. We'll be storing the OUT, FLO, and MO? files there. You can change the names of the files, and that will affect the behavior of Opus. I strongly suggest you don't put other files in this holding area. Outbound Matrix Traffic ----------------------- You have two primary methods for controlling phone calls made by your Opus system: the control file and the event manager. The control file method is in effect if there is no event to over-ride it. In other words, Opus will give priority to the event (described later). To disable outbound calls, put this into your control file: Matrix Send NOTHING To disable long distance outbound calls, put this into your control file: Matrix Send LOCAL With those two restrictions, Opus now attempts to send any outbound material it finds in the sub-directory declared as your Hold_Area. If you want to keep humans off-line during a critical mail period, include this: Matrix Allow MAIL ONLY IMPORTANT: You can over-ride these control file settings with the "Z" Behavior Windows described below. More on "Z" Windows ------------------- +----------------------------------------------+ | | | "But what HAPPENS during this event?" | | | | "Nothing. It's not a real event. A better | | phrase would be BEHAVIOR WINDOW." | | | +----------------------------------------------+ When a "Z" event is in progress, it's settings remain in effect until the next "Z" event. In other words, the settings do NOT RETURN TO THEIR ORIGINAL VALUE at the "end" of this event. Let's say you declare a "Z" event for every day of the week from 9am to noon. The behavior you describe in the "Z" event will be in effect for those three hours. Here's the part that needs to be stressed... at noon, the behavior will remain in effect unless there is a "Z" event declared then. That should probably be repeated... * You can setup matrix behavior in the control file. If Opus runs into a "Z" event that is in progress, those control file values are gone for the life of the program. * To actually "end" a "Z" event, you have to begin another "Z" event. In this case, the duration of the event means "go to these values whenever you find yourself in this time period." * The end of a "Z" event does NOT mean return to the old values. * Whew. NOTE: All of this does not mean that you can take the lazy way out and set your Z windows for a duration of 1 minute. You should still set the duration for the actual lenght of the window so that Opus will know what to do when you start the program in the middle of a window. You can use this event to set the following items: Local only.........No "Cost" phone calls are made Regular mail.......Outbound goes to all (except HOLDs) Continuous mail....Only packets (etc) marked for continuous mail are sent Mail only..........No human callers are allowed on-line No traffic.........Outbound mail is turned off Using the "!" command off the main menu, select the event section. Then just set an otherwise unused event to a type "Z". Additional selections will appear. Matrix Bundling --------------- There is no internal bundler (the thing that maintains message bundles destined for some other system). You can exit Opus with a pre-set ErrorLevel to call the bundler program when the contents of the matrix area changes. For example, if you call and enter a message into your network area, Opus will exit with an ErrorLevel of 11 *after* you have ended your regular session... Matrix After Edit Exit 11 For information on one possible bundling method, refer to "oMMM"... a stand-alone no-frills bundling program. Enabling File Requests ---------------------- If you want to allow file requests, put this into your control file: Matrix allow requests IMPORTANT: You can temporaraly over-ride these control file settings with the "Z" windows described earlier. Approval Listing ---------------- In addition, you will need a file containing a list of files approved for file requests. This is a standard, garden-variety text file. It MAY include wildcards. Declare the file like this: Matrix okfile c:\opus\okfile.lst This is a "raw" list. It should contain nothing other than file name. Only one file name should be on a line. The items must begin in the far left column. Example: c:\dl\pascal\*.* c:\net\node*.a?? c:\dl\forth\this.one ^ | | Pretend this starts way over there | <---------------------------------------------------------+ SYSTEM ADVERTISEMENT AND FILE LIST ---------------------------------- One more declaration will generalize your list of available files. In other words, if somebody wants to know what you have on-line that is available for requesting, the standard Opus method is to request a file called FILES. When Opus receives a request for FILES, it will automatically transmit the file you declare like this: Matrix avail c:\opus\filelist.arc NOTE: Do NOT put comments on the `okfile' or on the `avail' lines. In addition to a listing of files, it would be a good idea to include a statement that wildcards are not allowed on file requests (see below). This file can also tell the caller something about your system. You include the extension in the control file... so the file can be a TXT, DOC, ARC or any other kind of file. PLEASE do not use "filelist.arc" as the name of the file. For The POLE, we're using "POLELIST.LST". Using this scheme, every system can have a unique file name. This should make file management much easier on the caller. IMPLEMENTATION RESTRICTION -------------------------- The requesting system cannot use a wildcard in the file name. By letting you put wildcards in the list of approved files, it makes it a little tedious to allow wildcards in the request. Not impossible. Just tedious. So... to make things easy on the sysop... I made a design decision to make it harder on the calling system. This will probably change sometime down the line, but I have my hands too full to worry about such stinkin' nicities. As it were. ERRORS: NO SUCH FILE -------------------- This version of Opus sends the "avail" file if no requested files are available. Eventually this Oops file will be separate and configurable via the control file. BEFORE ANYBODY ASKS ------------------- No, Opus does not currently have a method for initiating file requests. Opus can only accept a file request from another system. SPECIAL MATRIX MENU ------------------- When Opus is waiting for a call, you can get to a special matrix section. Press "M" when you see the "Ready" status line. The menu includes these items: INFORMATION............generate a chart showing the status of pending outbound traffic. POLL...................call a system whether or not there is any pending outbound mail. If there is a connection, Opus will dynamically generate and transmit a dummy message bundle if there isn't a real one available. As many as 9 or 10 tries will be made. You can stop the poll by pressing <esc>. If no connection is made after several attempts, Opus will recycle to its on-line ("Ready") state. If a connection is made, you can expect any items to be transmitted ... even those marked as "hold". When you cancel a poll, you may have to press <esc> a couple of times. The first will cancel the current call. The second one will cancel the polling sequence. UNPACK.................process/toss any PKT files found in the current default sub-directory. This is the same thing as the familiar `-u' command line option. CLEAR UNDIALABLES......Delete all "*.$$#" marker files in the outbound area. Opus keeps these files to mark which boards have been called unsuccesfully. If these files are not deleted, Opus will never try them again. They can also be deleted automatically, using a "Z" maintance event. UNSUCCESSFUL CONNECTIONS ------------------------ Previous versions would make an undetermined number of phone calls to a remote system. Beginning with this version, a counter is maintained. It is incremented when there is a connection that does is not consumated. If there is a carrier but no matrix session, this counter gets bumped. TECHIE STUFF MOST CAN SKIP -------------------------- The counter is a 0-byte file in the outbound holding area. The file name is something like this: ########.$$# |||||||| | \||/\||/ | \/ \/ | net node counter The net and node are 4 character hex numbers. The counter can be anything from 0 to 9. If Opus finds such a file, it's supposed to refuse to make a call if the counter is 4 or greater. If it equals 4, you'll get a log entry. The "flag" for this counter is an "?" in the middle of the extension. The first character of the extension is also an "$"... but that is NOT guaranteed for future versions. You should use a wildcard for the first character if you want to be upward compatible. Sneaky Arrogant Hacker Trick: if you want to guarantee continued calls, try building a read-only file that looks like the counter file. It should have a low counter value. If the file is read-only, Opus will see it but will be unable to increment the counter. I should say this is totally untested, but it sounds like it might work. The reason for such a method is simple. A 0-byte file takes up NO disk space except for the directory entry. Plus, it is easy to access because DOS does a good job of buffering directories. Access routines are in DOS ... so they don't have to be in Opus. In other words, it seems like a good way to us "database code" that's already in your computer... and to do so without using up any disk space you don't already have allocated. PLEASE READ THIS PART --------------------- Here's the situation... if Opus finds the counter file showing it tried to call a board unsuccessfully... it will not make further calls. You can manually delete them to enable further calls to the board(s) in question by using the "Clear Undialables" command on the Matrix Menu. There is also a HOUSECLEANING Z-EVENT which will remove these Dollar-Sign Files. IMMEDIATE CALL -------------- When Opus is waiting for a call, you can force it to make an outbound call immediately. Press "C" when you see the "Ready" status message. If it feels it needs to, Opus will make a call. In other words, this does not force Opus to actually originate a matrix session unless there is sendable outbound traffic. WILD ECHOMAIL ------------- The unarc routine now uses wildcards. In other words, it will try to unarc "*.MO?" in your matrix hold area. If you get something from a message archiver other than oMMM (ie "TU?", "WE?"....), it will try to unarc that specific file. This change means that attached messages are no longer needed for archived messages! oMMM does not produce such a message. NEW MATRIX BEHAVIOR MASK ------------------------ Using the event setup menu, you can tell Opus not to exit after Crash Mail and ArcMail. The mask is called "Exits suppressed" on the menu. If you turn this on, then any "EXIT AFTER CRASHMAIL" and "EXIT AFTER ARCMAIL" in your control file are ignored. ------------------------------------------------------------------------------ MATRIX SESSION SCRIPTS ---------------------- +-------------------------------------------------------+ | | | "This is where the D.J. talks, Don't say anything." | | "O.k., eh." | | ---- Bob and Doug McKenzie | | | +-------------------------------------------------------+ Instead of a phone number, the "phone" field of a record in the node list can contain the name of a script file. Script files are in quotes... PHONE NUMBER: 555-1212 SCRIPT FILES: "555-1212" "HARDWIRE.CTL" "SATORE.SPT" All script files must be in the sub-directory you've declared as being the NET_INFO sub-directory. NOTE: This addition to Opus does not address any methods for getting a quoted file name into the node list. But if you can get them in, Opus will understand them. CONTENTS OF A SCRIPT FILE ------------------------- A script file is created with a text editor. Each line must contain a KEYWORD. In most cases, it will contain other material. The keyword must be in the far lefthand column of each line. The system is not sensitive to the case of keywords... upper- and lowercase is the same. Some keywords require additional information. You should put a single space after the keyword, then start typing the additional information. In other words, if you put a keyword then TWO spaces... the second space will be considered part of the additional information. KEYWORDS -------- In the examples below, please pretend the keywords appear in the far lefthand column! ----------------------------------------------- XMIT ... send something to the modem. As in the modem initialization string in the control file, Opus understands the following special characters: ~ ... slight pause | ... transmit a <cr> character EXAMPLE: xmit ATZ| xmit AT|~ATHO| ----------------------------------------------- DIAL ... transmit whatever additional information appears on the same line of the script, then wait for a modem response. If the modem reports any kind of failure (eg "BUSY"), the script will be terminated. NOTE: The dial "prefix" and "suffix" from the control file are NOT used here. EXAMPLE: dial 555-1212 ----------------------------------------------- PHONE ... a special-case way of transmitting the remote system's phone number. It works like XMIT. In other words, there's no waiting around for a response. ----------------------------------------------- WAIT ... wait for a character from the remote system. A 40 second period of no input will terminate the script. EXAMPLE: wait : wait = ----------------------------------------------- SESSION ... in most cases, this will be the last keyword in your scripts. It means Opus should begin a network session with the remote system. The session begins with whacking, if necessary. Then it moves through the SYNC procedure into the exchange of bundles and files. EXAMPLE: session ----------------------------------------------- DOS ... send a command to DOS. You can process something... or even summon a stand-alone netmail session-handler. EXAMPLE: dos DIR dos ARCA test *.pkt ----------------------------------------------- CARRIER ... if there's no carrier when Opus reaches this keyword, the script will terminate EXAMPLE: carrier ----------------------------------------------- INIT ... go through the normal modem initialization routine. ----------------------------------------------- BAUD ... set the computer's async port to the remote system's baud rate ----------------------------------------------- CHECKLIST --------- * Script file names are in quotes in the node list phone field. * All script files must be in the NET_INFO sub-directory. * Each line must have a keyword in the far lefthand column. * Most keywords require additional information. This information should be separated from the keyword by a single space character. * Most script files should end with "session" SAMPLE SCRIPT ------------- This script, for PC PURSUIT, was done by Rick Huebner: dos if exist outbound\007C00D2.$$? del outbound\007C00D2.$$? init baud xmit ~AT|~ATS0=0|~ATDT3417733|~~~~~~~~~~~~~~~~~~~~ carrier xmit |~D~| wait = xmit ~D1| wait @ xmit ~c dial214/12,username| wait = xmit ~password| wait T xmit ~~|~~I|~~ATZ| wait K xmit ~ATDT3809063| wait - xmit ~~~~~~ carrier session ------------------------------------------------------------------------------ SAMPLE MATRIX-ORIENTED BATCH FILE --------------------------------- +----------------------------------------------------------------------+ | | | Alright - all together now..Ctrl Alt Del,Ctrl Alt Del,Ctrl Alt Del. | | | +----------------------------------------------------------------------+ Any batch file for Opus must be able to respond to the following pre-defined ErrorLevels: VALUE | MEANING | ACTION -------+-------------------------------------+--------- 255 | an internal error generated by | recycle | MicroSoft "C". (eg STACK OVERFLOW) | | | 5 | reserved by Opus | recycle | | 4 | reserved by Opus | recycle | | 3 | very very serious error (No FOSSIL, | halt | no user file, etc) | | | 2 | minor error (i/o error) | recycle | | 1 | ^C (keyboard halt request) | halt | | 0 | ??? | recycle -------+-------------------------------------+--------- Here is a sample batch file: +----+----------------------------------------------------+ |Line| Batch file | +----+----------------------------------------------------+ | | | | 1 | :start | | 2 | E: | | 3 | cd E:\opus | | 4 | Opus %1 %2 %3 %4 %5 %6 | | 5 | if ERRORLEVEL 255 goto start | | 6 | if ERRORLEVEL 8 goto start | | 7 | if ERRORLEVEL 7 goto bundles | | 8 | if ERRORLEVEL 6 goto prepecho | | 9 | if ERRORLEVEL 3 goto end | | 10 | if ERRORLEVEL 2 goto start | | 11 | if ERRORLEVEL 1 goto end | | 12 | if ERRORLEVEL 0 goto start | | 13 | :prepecho | | 14 | E:\Opus\Util\ScanMail -maxmsgs 500 -short | | 15 | :bundles | | 16 | E:\Opus\oMMM -hE:\Opus\Outbound -cE:\Opus\oBUN.Ctl | | 17 | goto start | | 18 | :end | | 19 | | | | | +----+----------------------------------------------------+ NOTES: Line 5...The check for #255 isn't really needed here because the following line (ErrorLevel 8) will end up trapping 255. It's put here to stress that 255 is a possible ErrorLevel. Line 6...Checking for ErrorLevel 8 is a safety measure. It will trap any ErrorLevels above 8, too. In other words, the batch file is saying "If you get anything else just recycle." Line 7...Respond to "Matrix After Edit Exit 7". The ErrorLevel 7 means something in my netmail message area has changed. The only thing we need to do is put the new messages into bundles by calling oMMM. This ErrorLevel happens after somebody types a message in the netmail area. Line 8...ErrorLevel 6 is this: "Matrix After Arcmail Exit 6". It means we've gotten echomail that needs to be scanned then put into bundles. Line 13..PREPECHO calls ScanMail. Note that this falls through to the bundler. Line 19..With DOS, you always have to have a blank line when the last item is a label. ------------------------------------------------------------------------------ TECHNICAL STUFF ------------------------------------------------------------------------------ THE SESSION ----------- After a connection is established, there's some special handshaking. The purpose of the preliminaries is to let Opus determine whether or not it's dealing with another Opus (or compatible)... and what that other system can do. Opus is able to detect (or sniff out) another Opus system using the preliminaries. Once it does that, it knows it's safe to drop into a more efficient netmail session than the one currently in use by other<tm> systems. At the beginning of a netmail session, Opus transmits a character called YOOHOO<tm>. If the other system understands the meaning, it will respond. If not, Opus transmits the TSYNC character understood by other<tm> netmail programs. If the receiving system acts interested in the YOOHOO<tm>, the caller sends a full packet of information. It contains such things as the calling system's name and net/node. There's even space to add a password later. Also in the packet is a list of capabilities. Such things as "I can do YMODEM and ZMODEM" are in this part of the packet. This is the way the two systems agree on a file transfer protocol. If the receiving system gets the packet with no transmission errors, and if it understands everything in the packet, it sends back two things: * An acknowledgement of the packet * The beginning of YOOHOO/2U2<tm> The YOOHOO/2U2<tm> is just a YOOHOO<tm> going the opposite direction: from the receiver to the caller. At the end of the preliminaries, both systems know precisely who they are talking to... and the capabilities of the other side. Using a preset formula, they can agree on a file transfer protocol. The YOOHOO<tm> method has plenty of room to grow... to add additional capabilities. For example, in the works are some methods for real-time bundling which will do away with the need to scan and toss echomail. The method does not cause ill effects on any other<tm> netmail system currently in operation. If anything, the other<tm> system will simply think there was one byte of debris on the phone line in front of the traditional TSYNC character. Unless the other end responds to the YOOHOO<tm> character, no other data is transmitted. Although YOOHOO and YOOHOO/2U2 are trademarked and the handshake itself is copyrighted, this is NOT a proprietary method. Specifications are available on request. FILES IN THE OUTBOUND AREA -------------------------- - "OUT" files An "OUT" file is a regular IFNA-type message bundle. The file name is the remote system's net/node expressed as an 8-digit hex number. The file extension is ".OUT". For example, a bundle destined for 124/108 would be in a file called "007C006C.OUT". If present, the OUT file is sent using XModem/Crc. - Files listed in a "FLO" file A "FLO" file is normally used to contain a list of files declared as "File-Attach" in messages in the "OUT" file. In other words, if you create a "File-Attach" message, the message itself will be put into the "OUT" file, and the name of the file(s) to be sent will be put into the "FLO" file. The file name is the remote system's net/node expressed as an 8-digit hex number. The file extension is ".FLO". For example, a bundle destined for 124/108 would be in a file called "007C006C.FLO". If present, the FLO file is sent using the VBTS protocol. That stands for Voodoo-Bondage TeLink/Sealink. First, there is a MODEM7 file name. That is followed by a Sealink (or XModem) file transfer. Normally, this method is compatible with both Sealink and Telink receivers. IMPORTANT: If the first character of the file name listed in the flow file is "#", then Opus will truncate the file if it is successfully transmitted. In other words, if the line "#12345678.TU1" appears, Opus will send the file "12345678.TU1" and then make it a zero-length file if the transmission is consumated. Z EVENTS -------- The following is the specs on the Z event. It's not useful except to a programmer interested in twiddling or interpreting the schedule data file... /*-----------------------------------------------*/ /* */ /* EVENTS */ /* */ /*-----------------------------------------------*/ #define EXT_EVENT 'X' /* External event */ #define YELL_EVENT 'Y' /* Yell event */ #define SCHEDS 35 /* Max. # of events */ struct _time begin word year; /* Unused */ word month; /* 0..12 */ word day; /* 0..31 */ word daywk; /* 0..7 */ word hour; /* 0..23 */ word mins; /* 0..59 */ word sec; /* Unused */ end; /*-----------------------------------------------*/ /* Schedule file record */ /*-----------------------------------------------*/ struct _sched begin struct _time time; /* Starting time */ word len; /* Duration of event */ int enable; /* 1==Enabled */ word trigger; /* Unknown/unused */ word result; /* X errorlevel */ byte tag; /* Event type */ byte junk_1; /* */ word a; /* OPUS: Reserved */ word b; /* OPUS: Reserved */ word c; /* OPUS: Reserved */ word matrix_mask; /* Matrix ability */ byte junk_2; /* OPUS: Reserved */ byte GMT; /* OPUS: Set=GMT */ end; The `matrix_mask' field is valid only if `tag' is Z and `result' is 1. It is subject to contain debris or be otherwise defined in other cases. The chief cause of problems is solutions. -- Eric Sevareid -- ###